1. Field of Invention
The present invention relates generally to cryptographic processing of messages and more particularly to an improved architecture for cryptographic engines.
2. Description of Related Art
Assets are often protected or controlled to prevent loss of classified information, particularly if the implementation of the asset can be determined by reverse engineering. A means for protecting assets, often communication and data assets, is through the use of cryptography. Cryptography may refer to the encryption of information or data into an unreadable format. Only those with a key associated with the method of encryption may decipher the information or data.
Those assets which employ cryptography may be classified as Controlled Cryptographic Items (CCI) and are subject to special handling and protection policies. It would be relatively infeasible to provide such protection of a cryptographic system in a commercial application. A solution to this issue is the use of a non-Controlled Cryptographic Item (CCI) cryptographic engine, also known as a crypto engine. One example of a cryptographic engine is the Rockwell Collins JANUS Crypto Engine. A crypto engine may have implementation parameters loaded in volatile memory upon startup of the system and are completely erased upon removal of power.
A crypto engine may include several PCCs. Each PCC may include a Programmable Cryptographic Processor (PCP), as explained further herein and microcode that implements the crypto algorithm. In a conventional application of a crypto engine, a PCC must be zeroized (sanitized) between different messages passed through each PCC. Zeroization for a register may refer to a reset of the register. Zeroization for memory is more complicated; it involves writing zero's then one's to each location, and this cycle is typically repeated three times. A problem associated with sanitization of the PCC between different messages is the latency issues derived from such a process. As a result, a crypto engine must contain additional PCCs to process messages in an efficient manner. The additional PCCs are not necessarily required because of throughput requirements but because of the latency issues of setting up a PCC to process the new message—the latency caused by zeroizing between messages. If a single PCC could be trusted to not contaminate a message with previous data in the PCC, then this single PCC could process messages without zeroizing the PCC between each message. This would remove a significant amount of overhead and potentially allow the crypto engine to contain fewer PCCs. The overhead of zeroizing the PCC also arises when messages have differing classification levels.
Consequently, what is lacking in the prior art is a superior way of handling multiple messages within a single crypto engine so that costly latency via zeroizing of the PCC is eliminated.